home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c++ / 829 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  3.2 KB
  1. From: clamage@Eng.Sun.COM (Steve Clamage)
  2. Message-ID: <4ivagk$p3p@engnews1.Eng.Sun.COM>
  3. X-Original-Date: 22 Mar 1996 22:44:36 GMT
  4. Path: in2.uu.net!bounce-back
  5. Date: 23 Mar 96 08:12:21 GMT
  6. Approved: fjh@cs.mu.oz.au
  7. Newsgroups: comp.std.c++
  8. Subject: Re: Referencing pointers after delete
  9. Organization: Sun Microsystems Inc.
  10. References: <4iv8bd$5vh@galaxy.ucr.edu>
  11. Reply-To: clamage@Eng.Sun.COM
  12. X-Auth: PGPMoose V1.1 PGP comp.std.c++
  13.     iQBFAgUBMVOye+EDnX0m9pzZAQFXdwF9G0hYGyA4/quOu++aXZCBH6p5taMQ0cQw
  14.     a+UYcflz7ky3oSTd43V/th5BrCeAF7fy
  15.     =x3sY
  16.  
  17. In article 5vh@galaxy.ucr.edu, thp@cs.ucr.edu (Tom Payne) writes:
  18. >Steve Clamage (clamage@Eng.Sun.COM) wrote:
  19. >: You can't do anything useful in portable code with uninitialized pointers,
  20. >: or pointers which point to objects which are no longer available. The
  21. >: standard allows the implementation a great deal of leeway in trying to
  22. >: help by identifying such invalid uses.
  23. >
  24. >.... just as for arithmetic exceptions, which also engender "undefined
  25. >behavior."  But why the leeway to, say, reformat the disk, rather
  26. >than specifying the normal practice, which is to invoke a signal
  27. >handler, thereby, keeping the behavior defined?
  28.  
  29. Why should raising a signal be "normal practice"? Why not throwing an
  30. exception? What about time-critical programs which would rather risk an
  31. invalid pointer than pay the penalty of checking every pointer for validity?
  32.  
  33. If you specify the set of behaviors that are allowed when using an invalid
  34. pointer, every pointer must be checked except those that can be proved at
  35. compile time to be valid. If the runtime code does not check all the pointers,
  36. there isn't any way to predict what will happen if you use an invalid  one.
  37. (In general, that is. On specific platforms it might be possible, and the
  38. degree to which it is specified is deemed a "quality-of-implementation"
  39. issue.)
  40.  
  41. I don't know how to write a specification that says, "The implementation
  42. doesn't have to check pointers, but invalid pointers aren't allowed to do
  43. anything bad." I also don't know how to test an implementation for
  44. conformance to such a rule.
  45.  
  46. The philosophical question here is how much validity checking should be
  47. assured by the programming language. Should the implementation be required to
  48. check for invalid pointers, arithmetic overflow, underflow, loss of precision?
  49.  
  50. Some languages have such requirements. Some C and C++ implementations do
  51. indeed provide such checking. (The C and C++ definitions allow but do
  52. not require those checks.) My observation is that such programming
  53. languages and C/C++ implementations are not wildly popular. Maybe they
  54. should be, but they are not. That seems to validate the decision to leave
  55. those issues up to the implementation and its customers, in the sense that
  56. many C and C++ programmers don't seem to care much about those things. 
  57. ---
  58. Steve Clamage, stephen.clamage@eng.sun.com
  59. ---
  60. [ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
  61. [ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
  62. [ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
  63. [ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
  64. [ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]
  65.